The present invention relates to data communications. More specifically, it relates to the transmission of packets over a communications link that crosses multiple types of networks.
Connection oriented point-to-point communication links, such as a Layer 2 Tunneling Protocol (L2TP) tunnel, are an increasingly common feature of network infrastructures. Tunnels are prearranged connections established by agreement between internet service providers (ISPs). See Request for Comment (RFC) 2661 and Layer Two Tunnelling Protocol (L2TP), A. Valencia, et al., draft-ietf-pppext-12tp-16.txt, June 1999, herein incorporated by reference, available from the Internet Engineering Task Force (IETF) at www.ietf.org for more information.
FIG. 1 shows an architecture 10 involving an internet protocol (IP) network 70 to which tunnel initiator 30 is linked via network connection 32, tunnel initiator 40 is linked via network connection 42 and tunnel endpoint 50 is linked via network connection 52. A remote client 20 is linked to tunnel initiator 30 via communication link 22 that is tunneled through IP network 70 via tunnel connection 56 from tunnel initiator 30 to tunnel endpoint 50. Another remote client 24 is linked to tunnel initiator 40 via communication link 26 that is tunneled through IP network 70 via tunnel connection 66 from tunnel initiator 40 to tunnel endpoint 50. Tunnel endpoint device 50 is also connected to a Local Area Network 80 via network connection 54. A server device 84 is linked to LAN 80.
One example of a tunnel initiator or tunnel endpoint device is a network access server, such as that described in the patent to Dale M. Walsh et al., U.S. Pat. No. 5,528,595, which is fully incorporated by reference herein and describes an integrated network access server suitable for use in the present invention. Such a device has been commercialized widely by 3Com Corporation (previously U.S. Robotics Corp.) under the trade designation Total Control(trademark) Enterprise Network Hub. Network access servers similar in functionality, architecture and design are available from other companies, including Ascend Communications, Livingston Enterprises, Multitech, and others. The invention is suitable for implementation in network access servers from the above companies, and other similar devices.
An L2TP tunnel typically provides a conduit for communications between a client device served by a tunnel initiator and a server device served by tunnel endpoint, i.e. tunnel connection 56 between tunnel initiator 30 and tunnel endpoint 50 that transports communication between remote client 20 and server 84. Typically, a single tunnel slot provides the communication link between a client and server.
When a client device establishes a dial-up connection with a tunnel initiator (TI) 30 or 40, then the TI typically recognizes the client device as a tunnel client by means of an authentication protocol, such as RADIUS, see Request For Comment (RFC) 2138, herein incorporated by reference. An authentication, authorization and accounting (AAA) server 74, such as a RADIUS server, may be connected to IP network 70 to provide AAA services to the tunnel initiators and other devices on the network. The authentication process can be adapted to provide an address for a tunnel endpoint device for the client. There exist other means for identifying a tunnel client, such as through the use of a mobile identification number (MIN) in mobile applications or, for protocols not directed toward mobile applications, the use of a Dial-up Number Information Service (DNIS) or Automatic Number identification (ANI), that can also be used to identify a tunnel endpoint for a client and establish a tunnel connection. Alternatively, the client device itself may provide the tunnel endpoint address. In still another approach, each TI may have a pre-constructed table containing entries that associate a client device identifiers with a tunnel endpoint address value. Independent of how the tunnel endpoint address is obtained, the tunnel initiator will establish a tunnel connection to the tunnel endpoint device.
FIG. 2 is a protocol stack diagram illustrating an example of the protocol relationships in a conventional tunnel structure. As is known in the art, the Open System Interconnection (xe2x80x9cOSIxe2x80x9d) model is used to describe computer networks. The OSI model consists of seven layers including from lowest-to-highest, a physical, data-link, network, transport, session, application and presentation layer. The physical layer, or layer 1, transmits bits over a communication link. The data link layer, or layer 2, transmits error free frames of data. The network layer, or layer 3, transmits and routes data packets. FIG. 2 illustrates an example of protocol stacks in each of the remote client 20, tunnel initiator 30, and tunnel endpoint 50, and server 84 for tunnel connection 56 of FIG. 1. Link 22-for remote client 20 to tunnel initiator 30 can involve a wireless link protocol, such as the Radio Link Protocol (RLP), a dial-up type protocol, such as the Point-to-Point Protocol (PPP) or Serial Line Interface Protocol (SLIP), a network type protocol, such as the Media Access Control (MAC) protocol of Ethernet, or other types of links as the application demands. Thus, a layer 1 to layer 1 (L1) session is represented at the lowest level of the protocol stacks in FIG. 2 between remote client 20 and tunnel initiator 30. Because the link between the remote client and tunnel initiator is typically a serial link, a serial data link protocol session exists at layer 2 (L2) between remote client 20 and tunnel initiator 30.
When a tunnel is established from tunnel initiator 30 to tunnel endpoint 50, there are layer 1 (L1) and layer 2 (L2) sessions between the tunnel servers as well as a L2TP session that represents the tunnel connection 56 itself. Once the tunnel connection is established, a session between network layer peers, such as internet protocol (IP) peers, in the remote client 20 and tunnel endpoint 50 typically exists. A session also typically exists between transport layer peers in the remote client 20 and the server 84. Transport layer protocols such as Transmission Control Protocol (xe2x80x9cTCPxe2x80x9d) and User Datagram Protocol (xe2x80x9cUDPxe2x80x9d) are often used over IP in computer networks. The Transmission Control Protocol provides a connection-oriented, end-to-end reliable protocol designed to fit into a layered hierarchy of protocols that support multi-network applications. The User Datagram Protocol provides a transaction oriented datagram protocol, where delivery and duplicate packet protection are not guaranteed.
A second IP (IP2) and UDP (UDP2) peer relationship exists for the routing of packets over the network 70 between the tunnel initiator 30 and the tunnel endpoint 50. In addition, a PPP peer relationship typically exists between the remote client 20 and the tunnel endpoint 50, where the PPP packets become the payload for the tunnel connection between the tunnel initiator 30 and tunnel endpoint 50. PPP is described in further detail in RFC 1661, herein incorporated by reference for all purposes.
Occasionally, a tunnel connection is desired between a remote client and a server where a tunnel initiator serving the remote client and a tunnel initiator serving the server reside on different types of networks. FIG. 3 is a functional block diagram illustrating an architecture 100 where tunnel initiator 30 resides on IP network 70 and tunnel endpoint 150 serving server 84 resides on Asynchronous Transfer Mode (ATM) network 160. A gateway device 140 is configured to recognize address on both the IP network 70 and the ATM network 160 and route traffic between the two networks.
In order to tunnel traffic between remote client 20 and server 84, two tunnel connections must be established: a first tunnel 134 from tunnel initiator 30 to gateway 140 and a second tunnel 148 from gateway 140 to tunnel endpoint 150. When tunnel initiator 30 queries AAA server for the endpoint device fore remote client 20, the AAA server returns an address for tunnel endpoint 150 on ATM network 160. The routing tables established for IP network 70 will return an address for gateway 140 on IP network 70 as the next hop for traffic to the address for tunnel endpoint 150. Tunnel connection 134 is then established from tunnel initiator 30 to gateway 140.
When gateway 140 receives tunneled packets via tunnel connection 134 that are addressed to tunnel endpoint device 150. The gateway device then establishes tunnel 148 through ATM network 160 to tunnel endpoint 150. Tunnel packets from remote client 20 are sent through tunnel connection 134 to gateway device 140. Gateway device 140 takes the packets received through tunnel 134, de-tunnels the packets, re-tunnels the packets for tunnel connection 148, and retransmits the re-tunneled packets through tunnel 148 to tunnel endpoint 150.
FIG. 4 is a protocol stack diagram illustrating an example of the protocol stacks resulting from tunnel connections 134 and 148 in architecture 100 of FIG. 3. After tunnel connections 134 and 148 are established, a data packet sent from remote client 20 to tunnel initiator 30 over link 22 is passed up to an L2TP peer in tunnel initiator 30 for a first L2TP connection (L2TP1), which sends the packet through tunnel connection 134 to the corresponding L2TP1 peer in gateway 140. A second IP session (IP2) and second UDP session (UDP2) for tunnel connection 134 through IP network 70 originate in tunnel initiator 30 and terminate in gateway 140. As the packet passes through the layers L2TP1, IP2 and UDP2 on the left-hand side of the stack for gateway 140, the packet headers for these layers are stripped away. Once the packet reaches the top of the stack shown for gateway 140, it has been de-tunneled from tunnel connection 134.
At this point, the packet must be re-tunneled for tunnel connection 148. The packet travels down the right-hand side of the stack for gateway 140. The packet passes down through a a second L2TP session (L2TP2) corresponding to the second tunnel connection 148. The packet is thus re-tunneled for tunnel connection 148. The packet then passes into an ATM stack entity that will route packets based upon virtual path identifier (VPI) and virtual channel identifier (VCI) values through ATM network 160.
When the packet reaches tunnel endpoint 150 on ATM network 160, the packet is passed up through the L2TP2 layer and IP2 layers of the tunnel endpoint 150 stack in order to de-tunnel the packet from tunnel connection 148. The packet is then forwarded to server 84 over LAN 80.
The processing involved in de-tunneling and re-tunneling packets represents a significant load upon the resources of gateway device 140. This processing also introduces delay in the transmission of packets from tunnel initiator 30 to tunnel endpoint 150.
Thus, the need remains for a method for efficiently transporting tunnel packets across multiple networks of different types.
In accordance with preferred embodiments of the present invention, some of the problems associated with combining multiple tunnel endpoint devices are overcome.
An embodiment of a method, according to the present invention, for method for establishing a tunnel connection from a tunnel initiator device on a first network of a first type and a tunnel endpoint device on a second network of a second type, calls for providing a translator device coupled to the first and second networks and includes receiving a connection request message in the translator device from the tunnel initiator, the connection request message including a source address field having a first address value corresponding to the tunnel initiator, a source tunnel identifier field having a first tunnel identifier value, and a host name field having a desired host name value. The method then proceeds by resolving the desired host name value to a second address value corresponding to the tunnel endpoint, creating a data entry accessible to the translator device and having first and second address columns and first and second tunnel identifier columns, and storing the first address value in the first address column of the data entry, the first tunnel identifier value in the first tunnel identifier column of the data entry, and the second address value in the second address column of the data entry. The method then sets forth inserting the second address value from the second address column of the data entry into the destination address field of the connection request message and re-transmitting the connection set-up request onto the second network. The method then calls for receiving a connection reply message in the translator device, the connection reply message including a source address field having the second address value, a source tunnel identifier field having a second tunnel identifier value, and a destination tunnel identifier field having the first tunnel identifier value, using the second address value from the source address field and the first tunnel identifier value from the destination tunnel identifier field of the connection reply message to find the matching data entry having the second address value in the second address column and the first tunnel identifier column, respectively, and storing the second tunnel identifier value in the second tunnel identifier column of the data entry. The method then proceeds by inserting the first address value from the first address column into the destination field of the connection reply message and re-transmitting the connection reply message onto the first network.